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IANA Registries for BGP Extended Communities 


Abstract 


This document reorganizes the IANA registries for the type values and 
sub-type values of the BGP Extended Communities attribute and the BGP 
IPv6-Address-Specific Extended Communities attribute. This is done 
in order to remove interdependencies among the registries, thus 
making it easier for IANA to determine which codepoints are available 
for assignment in which registries. This document also clarifies the 
information that must be provided to IANA when requesting an 
allocation from one or more of these registries. These changes are 
compatible with the existing allocations and thus do not affect 
protocol implementations. The changes will, however, impact the 
"TANA Considerations" sections of future protocol specifications. 
This document updates RFC 4360 and RFC 5701. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7153. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


RFC 4360 [RFC4360] defines the BGP "Extended Communities" (EC) 
attribute. This attribute consists of a sequence of eight-octet 
"extended communities". The high-order octet is defined to be the 
"Type" field. Each Type has a range of values for "Transitive 
Extended Community Types" and a range of values for "Non-transitive 
Extended Community Types". Some of these ranges are further 
subdivided into a sub-range of values to be assigned by IANA under 
the "Standards Action" policy, a sub-range of values to be assigned 
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by IANA under the "First Come First Served" policy, and a sub-range 
for "experimental use". (See [RFC5226], [RFC7120], and [RFC3692] for 
an explanation of these policies.) 


For some Extended Community Types, the second octet of the Extended 
Community is a "Sub-Type" field, and the remaining six octets are the 


"Value" field. These are referred to as "Extended Types". For other 
types, there is no "Sub-Type" field, and the "Value" field contains 
seven octets. These are referred to as "Regular Types". 


RFC 4360 is not very specific about how the IANA registries for 
Extended Community Types and/or Sub-Types are to be organized, and 
this has led to some confusion. The purpose of this document is to 
reorganize the registries to make the IANA codepoint allocation task 
more straightforward. 


2. Types, Sub-Types, and Registries 


The high-order octet of an Extended Community will be known as the 
"Type" field. 


There will be one IANA registry for "Transitive Extended Community 
Types" (see Section 5.1.1) and one for "Non-transitive Extended 
Community Types" (Section 5.1.2). Each registry specifies three 
ranges, and each range is associated with a particular IANA 
allocation policy. 


There will be a set of IANA registries for Extended Community 
Sub-Types (see Section 5.2). Each such registry will have a range of 
Ox00-OxFF. Values in the range O0x00-OxBF are assignable by IANA 
according to the "First Come First Served" allocation policy of 
[RFC5226]. Values in the range OxCO-OxFF are assignable by IANA 
according to the "IETF Review" allocation policy of [RFC5226]. 


If a particular Type has Sub-Types, that Type’s entry in its Type 
registry identifies its Sub-Type registry. Note that some Types do 
not have Sub-Types. When the request is made to establish a new Type 
registry, the request must specify whether or not there is to be a 
Sub-Type registry associated with that Type. 


Whether a given Type has Sub-Types is determined when the Type is 
initially defined; this cannot be changed later. 


3. Applicability to IPv6-Address-Specific EC Attribute 
RFC 5701 [RFC5701] defines the IPv6-Address-Specific Extended 


Community to be a 20-octet quantity whose high-order two octets may 
be considered to be the "Type" field. The high-order octet is either 
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0x00, indicating a transitive Extended Community; or 0x40, indicating 
a Non-transitive Extended Community. The second octet is said to be 
a "Sub-Type", and it is suggested that the Sub-Types are the same as 
the Sub-Types for the IPv4-Address-Specific Extended Community. 
However, the existing IANA codepoint allocations for this octet do 
not always match the corresponding allocations for the 
IPv4-Address-Specific Extended Community Sub-Types. 


This document modifies RFC 5701 by removing any requirement for the 
values of the second octet of the IPv6-Address-Specific Extended 
Community Type codepoints to match the codepoints in either of the 
IPv4-Address-Specific Sub-Types registries. 


This document requests IANA to create two IPv6-Address-Specific 
Extended Community registries -- one for transitive communities and 
one for non-transitive communities. See Section 5.3. 


4. How to Request EC Type and/or Sub-Type Codepoints 


When a codepoint is needed for a new Extended Community, the 
requester should first determine whether an existing Type can be 
used. If so, IANA should be asked to allocate a codepoint from the 
corresponding Sub-Type registry, if there is one. 


If a new Extended Community Type is needed, the requester should ask 
IANA to allocate a new type from the "BGP Transitive Extended 
Community Types" registry, the "BGP Non-Transitive Extended Community 
Types" registry, or both. It is up to the requester to state whether 
an allocation is needed from one or both of these registries. When 
an allocation from both registries is requested, the requester may 
find it desirable for both allocations to share the same low-order 
six bits. If so, it is the responsibility of the requester to 
explicitly request this of IANA. 


Of course, any request for a codepoint from a particular registry 
must follow the defined registration procedures for that registry. 


If a new Extended Community Type is needed and the new Type is to 
have Sub-Types, the requester should specify whether an existing 
Sub-Type registry can be used for the new Type or a new Sub-Type 
registry is needed. (At the current time, every Type that has 
Sub-Types is associated with a unique Sub-Type registry. It is 
possible that in the future a new Type registry may be created that 
is associated with a pre-existing Sub-Type registry.) In either 
case, if a new Sub-Type value needs to be allocated from a particular 
Sub-Type registry, the request should explicitly identify the 
registry. 
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If the creation of a new Sub-Type registry is requested, the range of 
values is always 0x00-OxFF. It is recommended that the allocation 
policy described in Section 2 be used, i.e., 0x00-0xBF to be 
allocated by IANA under the "First Come First Served" policy and 
OxCO-OxFF to be allocated by IANA under the "IETF Review" policy. 


Commonly, a new Extended Community is defined such that it can be of 
several Types. For example, one may want to define a new Extended 
Community so that it can be either transitive or non-transitive, 
either the two-octet AS Number Type or the four-octet AS Number Type, 
etc. The requester is responsible for explicitly asking IANA to 
allocate codepoints in all the necessary Type and/or Sub-Type 
registries. 


When a new Extended Community is defined, it may be necessary to ask 
IANA to allocate codepoints in several Sub-Type registries. In this 
case, it is a common practice to ask IANA to allocate the same 
codepoint value in each registry. If this is desired, it is the 
responsibility of the requester to explicitly ask IANA to allocate 
the same value in each registry. 


When a new Extended Community Sub-Type codepoint is allocated, it may 
also be desirable to allocate a corresponding value in one or both of 
the IPv6-Address-Specific Extended Community registries. The 
requester is responsible for requesting this allocation explicitly. 
If the requester would like the same numerical value to be allocated 
in an IPv6-Address-Specific Extended Community registry that is 
allocated in some other registry, it is the responsibility of the 
requester to explicitly ask this of IANA. 


5. IANA Considerations 


IANA has replaced the pre-existing BGP Extended Communities 
registries with the registries described in this section. 


The registries reproduced below do not include the "references" or 
"date" fields for the individual codepoints in the registries, 
because it is difficult to incorporate those within the 72-character 
line limitation of RFCs. The references and associated dates have 
been copied from the existing registries when creating the new 
registries; the authors have worked with IANA to ensure that this 
information has been carried over correctly to the reorganized 
registry. As this document does not change the usage or semantics of 
any of the codepoints, the references associated with the individual 
codepoints do not change. 


On the other hand, the references for each of the registries defined 
in this section have been changed to refer to this document. 
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5.1. Registries for the "Type" Field 
5.1.1. Transitive Types 


The following note has been added to the "BGP Transitive Extended 
Community Types" registry. 


This registry contains values of the high-order octet (the "Type" 
field) of a Transitive Extended Community. 


Registry Name: BGP Transitive Extended Community Types 


RANGE REGISTRATION PROCEDURES 

0x00-0x3F First Come First Served 

0x80-0x8F Experimental Use (see RFC 3692) 

0x90-OxBF Standards Action 

TYPE VALUE NAME 

0x00 Transitive Two-Octet AS-Specific Extended 


Community (Sub-Types are defined in the 
"Transitive Two-Octet AS-Specific Extended 
Community Sub-Types" registry) 


0x01 Transitive IPv4-Address-Specific Extended 
Community (Sub-Types are defined in the 
"Transitive IPv4-Address-Specific Extended 
Community Sub-Types" registry) 


0x02 Transitive Four-Octet AS-Specific Extended 
Community (Sub-Types are defined in the 
"Transitive Four-Octet AS-Specific Extended 
Community Sub-Types" registry) 


0x03 Transitive Opaque Extended Community 
(Sub-Types are defined in the "Transitive 
Opaque Extended Community Sub-Types" 


registry) 
0x04 QoS Marking 
0x05 CoS Capability 
0x06 EVPN (Sub-Types are defined in the "EVPN 


Extended Community Sub-Types" registry) 


0x08 Flow spec redirect/mirror to IP next-hop 
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0x80 


IANA Registries for BGP ECs March 2014 


Generic Transitive Experimental Use Extended 
Community (Sub-Types are defined in the 
"Generic Transitive Experimental Use Extended 
Community Sub-Types" registry) 


5.1.2. Non-Transitive Types 


The following note has been added to the "BGP Non-Transitive Extended 
Community Types" registry. 


This registry contains values of the high-order octet (the "Type" 
field) of a Non-transitive Extended Community. 


Registry Name: 


RANGE 


0x40-0x7F 
OxCO0O-0xCF 
OxDO-0xFF 


TYPE VALUE 


0x40 


0x41 


0x42 


0x43 


0x44 
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BGP Non-Transitive Extended Community Types 


REGISTRATION PROCEDURES 


First Come First Served 
Experimental Use (see RFC 3692) 
Standards Action 


NAME 


Non-Transitive Two-Octet AS-Specific Extended 
Community (Sub-Types are defined in the 
"Non-Transitive Two-Octet AS-Specific Extended 
Community Sub-Types" registry) 


Non-Transitive IPv4-Address-Specific Extended 
Community (Sub-Types are defined in the 
"Non-Transitive IPv4-Address-Specific Extended 
Community Sub-Types" registry) 


Non-Transitive Four-Octet AS-Specific Extended 
Community (Sub-Types are defined in the 
"Non-Transitive Four-Octet AS-Specific Extended 
Community Sub-Types" registry) 


Non-Transitive Opaque Extended Community 
(Sub-Types are defined in the "Non-Transitive 
Opaque Extended Community Sub-Types" registry) 


QoS Marking 
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5.2. Registries for the "Sub-Type" Field 
5.2.1. EVPN Extended Community Sub-Types 


The following note has been added to the "EVPN Extended Community 
Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x06. 


Registry Name: EVPN Extended Community Sub-Types 


RANGE REGISTRATION PROCEDURE 
0x00-OxBF First Come First Served 
OxCO-OxFF IETF Review 

SUB-TYPE VALUE NAME 

0x00 MAC Mobility 

0x01 ESI MPLS Label 

0x02 ES Import 
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5.2.2. Transitive Two-Octet AS-Specific Extended Community Sub-Types 


The following note has been added to the "Transitive Two-Octet 
AS-Specific Extended Community Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x00. 


Registry Name: Transitive Two-Octet AS-Specific Extended 
Community Sub-Types 


RANGE REGISTRATION PROCEDURE 
0x00-OxBF First Come First Served 
OxCO-OxFF IETF Review 

SUB-TYPE VALUE NAME, 

0x02 Route Target 

0x03 Route Origin 

0x05 OSPF Domain Identifier 
0x08 BGP Data Collection 
0x09 Source AS 

Ox0A L2VPN Identifier 

0x10 Cisco VPN-Distinguisher 


5.2.3. Non-Transitive Two-Octet AS-Specific Extended Community 
Sub-Types 


The following note has been added to the "Non-Transitive Two-Octet 
AS-Specific Extended Community Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x40. 


Registry Name: Non-Transitive Two-Octet AS-Specific Extended 
Community Sub-Types 


RANGE REGISTRATION PROCEDURE 

0x00-OxBF First Come First Served 

OxCO-OxFF IETF Review 

SUB-TYPE VALUE NAME 

0x04 Link Bandwidth Extended Community 
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5.2.4. Transitive Four-Octet AS-Specific Extended Community Sub-Types 


The following note has been added to the "Transitive Four-Octet 
AS-Specific Extended Community Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x02. 


Registry Name: Transitive Four-Octet AS-Specific Extended 
Community Sub-Types 


RANGE REGISTRATION PROCEDURE 
0x00-OxBF First Come First Served 
OxCO-OxFF IETF Review 

SUB-TYPE VALUE NAME, 

0x02 Route Target 

0x03 Route Origin 

0x04 Generic 

0x05 OSPF Domain Identifier 
0x08 BGP Data Collection 
0x09 Source AS 

0x10 Cisco VPN Identifier 


5.2.5. Non-Transitive Four-Octet AS-Specific Extended Community 
Sub-Types 


The following note has been added to the "Non-Transitive Four-Octet 
AS-Specific Extended Community Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x42. 


Registry Name: Non-Transitive Four-Octet AS-Specific 
Extended Community Sub-Types 


RANGE REGISTRATION PROCEDURE 
0x00-OxBF First Come First Served 
OxCO-OxFF IETF Review 

SUB-TYPE VALUE NAME 

0x04 Generic 
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5.2.6. Transitive IPv4-Address-Specific Extended Community Sub-Types 


The following note has been added to the "Transitive 
IPv4-Address-Specific Extended Community Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x01. 


Registry Name: Transitive IPv4-Address-Specific Extended 
Community Sub-Types 


RANGE REGISTRATION PROCEDURE 

0x00-OxBF First Come First Served 

OxCO-OxFF IETF Review 

SUB-TYPE VALUE NAME 

0x02 Route Target 

0x03 Route Origin 

0x05 OSPF Domain Identifier 

0x07 OSPF Route ID 

Ox0A L2VPN Identifier 

0x0B VRF Route Import 

0x10 Cisco VPN-Distinguisher 
5.2.7. Non-Transitive IPv4-Address-Specific Extended Community 

Sub-Types 


The following note has been added to the "Non-Transitive 
IPv4-Address-Specific Extended Community Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x41. 


Registry Name: Non-Transitive IPv4-Address-Specific Extended 
Community Sub-Types 


RANGE REGISTRATION PROCEDURE 
0x00-OxBF First Come First Served 
OxCO-OxFF IETF Review 


None Assigned 
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5.2.8. Transitive Opaque Extended Community Sub-Types 


The following note has been added to the "Transitive Opaque Extended 
Community Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x03. 


Registry Name: Transitive Opaque Extended Community 


Sub-Types 
RANGE REGISTRATION PROCEDURE 
0x00-OxBF First Come First Served 
OxCO-OxFF IETF Review 
SUB-TYPE VALUE NAME 
0x06 OSPF Route Type 
0x0B Color Extended Community 
0x0C Encapsulation Extended Community 
0x0D Default Gateway 


5.2.9. Non-Transitive Opaque Extended Community Sub-Types 


The following note has been added to the "Non-Transitive Opaque 
Extended Community Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x43. 


Registry Name: Non-Transitive Opaque Extended Community 


Sub-Types 
RANGE REGISTRATION PROCEDURE 
0x00-OxBF First Come First Served 
OxCO-OxFF IETF Review 
SUB-TYPE VALUE NAME 
0x00 BGP Origin Validation State 
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5.2.10. Generic Transitive Experimental Use Extended Community 
Sub-Types 


The following note has been added to the "Generic Transitive 
Experimental Use Extended Community Sub-Types" registry: 


This registry contains values of the second octet (the "Sub-Type" 
field) of an extended community when the value of the first octet 
(the "Type" field) is 0x80. 


Registry Name: Generic Transitive Experimental Use Extended Community 


Sub-Types 

RANGE REGISTRATION PROCEDURE 

0x00-OxBF First Come First Served 

OxCO-OxFF IETF Review 

SUB-TYPE VALUE NAME 

0x06 Flow spec traffic-rate 

0x07 Flow spec traffic-action (Use of the 
"Value" field is defined in the 
"Traffic Action Fields" registry) 

0x08 Flow spec redirect 

0x09 Flow spec traffic-remarking 

Ox0A Layer2 Info Extended Community 


Note: RFC 5575 contains narrative text that declares the "Flow spec 
traffic-rate" to be non-transitive but then assigns it a codepoint 
that indicates that it is transitive. Addressing this error in 
RFC 5575 is not within the scope of this document. 

5.2.11. Registries for the "Value" Field 
At the time of the writing of this document, there is only one 
registry containing codepoints for the "Value" field of an Extended 
Community. 


5.2.11.1. Traffic Action Fields 


This registry has not been modified. 
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5.3. Registries for IPv6-Address-Specific ECs 


5.3.1. Transitive Types 


The following note has been added to the "Transitive 
IPv6-Address-Specific Extended Community Types" registry: 


March 2014 


This registry contains values of the two high-order octets of an 
IPv6-Address-Specific Extended Community. 


Registry Name: Transitive IPv6-Address-Specific Extended 
Community Types 


RANGE 


0x0000-0x00FF 


TYPE VALUE 


0x0002 
0x0003 
0x0004 
0x000B 
0x0010 
0x0011 


REGISTRATION PROCEDURE 
First Come First Served 
NAME 


Route Target 

Route Origin 

OSPFv3 Route Attributes 
VRF Route Import 

Cisco VPN-Distinguisher 
UUID-based Route Target 


5.3.2. Non-Transitive Types 


(deprecated) 


The following note has been added to the "Non-Transitive 
IPv6-Address-Specific Extended Community Types" registry: 


This registry contains values of the two high-order octets of an 
IPv6-Address-Specific Extended Community. 


Registry Name: Non-Transitive IPv6-Address-Specific Extended 
Community Types 


RANGE 
0x4000-0x40FF 


None assigned 


REGISTRATION PROCEDURE 


First Come First Served 


6. Security Considerations 


No security considerations are raised by this document. 
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